MDEV-40634 Const MEMORY table's BLOB outlives the lock protecting it - #5490

https://jira.mariadb.org/browse/MDEV-40634

The defect

A single-row table is read once during optimization and its row kept in
record[0] for the rest of the statement. JOIN::optimize_stage2() then
releases the lock on every const table, on the premise stated in its own
comment: "It's safe to ignore result code as all tables where opened for read
only."

That premise assumes a read leaves a copy of the row behind. MEMORY with a
blob does not. hp_read_blobs() answers the read by pointing record[0] at the
blob data inside HP_SHARE rather than copying it, so from the moment the lock
is dropped another connection is free to overwrite, free or recycle those bytes
— and the statement goes on reading them.

Observed on 06cfb8d0c36 (this PR's base), with LENGTH() still reporting 4000
throughout because the length lives in record[0] and only the data moved:

CHECK TABLE reports OK in both cases: the table is undamaged, the corruption
is entirely in the reader's row.

Pre-existing in the shipped HEAP-blob feature, not introduced by any of the
open fix branches.

The fix

GET_LOCK_SKIP_ZERO_COPY_ROWS drops such tables from the lock set
get_lock_data() builds, exactly as GET_LOCK_SKIP_SEQUENCES already does, and
the const-table unlock passes it.

The skip is opt-in rather than a rule because mysql_lock_remove() also reaches
mysql_unlock_some_tables(), and there the unlock is permanent and must not be
skipped.

Cost: a MEMORY blob const table now stays read-locked for the whole statement
and blocks writers, which is the price every non-const MEMORY table already
pays.

Only the early-unlock path is affected

The three functions that release a lock before the end of a statement were
audited; this is the only unsafe caller.

• mysql_unlock_read_tables() — JOIN::join_free, safe: cleanup(full) runs
  first and requires all cursors closed.
• mysql_lock_remove() — every call site immediately follows with
  ha_close() / close_thread_table() / drop_temporary_table(), so no
  record[0] survives.

Non-transactional temporary tables need no handling: get_lock_data() already
drops them from the lock set, so they can neither be early-unlocked nor raced.

Testing

mysql-test/suite/heap/blob_const_unlock.test, deterministic, ~20 ms, covering
both ways the memory changes hands.

Unit-test-first verified: against the pre-fix binary the test reproduces both
failure modes, and the only difference between the pre-fix and fixed runs is the
two blob reads.

The reader is parked with GET_LOCK() rather than with a stored function. This
is load-bearing: a stored function puts the statement into prelocked mode
(DML_prelocking_strategy::handle_routine() sets need_prelocking for any
function, even one that touches no tables), and the const-table unlock is
guarded by !thd->locked_tables_mode, so a function-based test passes
vacuously against the broken build.

• heap.blob_const_unlock — 20/20 repeats
• full main,heap sweep — 1426/1426, zero retries
• heap unit tests — 9/9